Computing systems generally include a system bus for inserting input/output (I/O) interface circuits to connect the computing system to peripheral I/O devices. Such circuits are often known as host adapters, I/O interfaces, or I/O processors (IOP). The current trend for high-end networking and storage technology is pushing more functionality down to a low level driver, while at the same time demanding higher performance. To meet these demands, hardware vendors have developed intelligent host adapters that contain their own I/O controller circuits and associated processing capability for processing I/O transactions such as for RAID controllers. Intelligent host adapters may include significant local processing power and local memory use for processing host computer I/O requests and for controlling the attached I/O devices. New I/O architectures have been developed incorporating intelligent host adapters to relieve the host of interrupt intensive I/O tasks greatly improving I/O performance and high bandwidth applications, such as client server processing.
One such I/O architecture is known as intelligent I/O (I2O). The I2O standards are published and maintained by an industry group known as the I2O Special Interest Group. The I2O Standard, Version 2, can be found at “www.intelligent-IO.com.” The I2O interface standard defines layers of an interface structure between, for example, the host computer system and an intelligent host adapter. The standard simplifies the device driver modules for I/O interface devices by isolating device dependencies in the modules. Driver modules written in conformance with the standard are also more portable among a variety of system architectures and operating systems. The I20 specification partitions the device driver into a first portion that contains all the Operating System (OS) specific code and a second portion containing all the hardware specific code unique to a particular class of I/O device. Accordingly, OS vendors need only produce one OS specific module for each class of an I/O device. Similarly, hardware vendors only need to produce a single version of the hardware device modules for a specific I/O adapter. In this manner, the I2O standard provides an I/O device driver architecture that is independent of both the I/O device and the host operating system.
A typical I2O driver consists of an operating system specific module (OSM) and a hardware device module (HDM). The OSM and the HDM are autonomous and can perform independent tasks without sending data over a system I/O bus in the host computer. An HDM and OSM interface with each other through a communication system comprised of a message layer and a transport layer. This communication system is similar to a connection oriented networking protocol. For example, in a connection oriented network protocol, two parties interested in exchanging information utilize a message layer to set up a connection and to exchange control information and data. In the I2O model, the message layer sets up a communication session between the HDM and the OSM and the corresponding transport layer defines how the HDM and the OSM share information.
In a typical application, when the OSM is presented with a request from the host operating system, it translates the request into an I2O message and dispatches it to the appropriate HDM for processing. When the HDM has completed the request, it dispatches the results back to the OSM by sending a message to the I2O message layer. The host layers in an I2O host system and an I2O intelligent adapter communicate with one another via shared memory data structures. Shared memory is accessible via the common system bus interconnecting the communicating nodes, for example, the host system and the intelligent adapter. Specifically, the I2O interface defines a number of standard queues and other data structures commonly accessible in memories shared between the respective processors and the host system and the intelligent adapters.
The peripheral component interconnect (PCI) bus has become a popular system bus for direct connection of host adapters to the host system. In such a system, the host system may directly access the local memory of the host adapter. Similarly, the host adapter may directly access the memory of the host system. Using such direct access to one another's memory, it is common to use direct memory access (DMA) in host adapters to perform the transfers of data with minimal overhead imposed on the general purpose processing power both the host system and the host adapter.
The I2O standard includes four circular queues for messaging: 1) an inbound free queue, 2) an inbound post queue, 3) an outbound free queue and (4) an outbound post queue. The inbound queues allow the host to obtain a pointer to a buffer by reading the inbound free queue and writing the message to this buffer. Once the message is written, the pointer to the buffer is written to the inbound post queue. Conversely, the outbound queues are used for the adapter's firmware to deliver returned message status to the host in a similar fashion as the inbound queues. For example, when the host needs to deliver a command to the adapter, the host sets up the command in the host's memory and then writes the command's address to the inbound post queue. In this technique, the adapter device driver immediately writes the pointer of this command to the inbound post queue requiring the device driver to access the PCI bus for each individual command delivery. In a system where multiple adapters are installed, the time the device driver spends in kernel privileged time may be extended due to other bus masters contending for access to the PCI bus.
Upon detecting a write to the inbound post queue, the adapter interrupts the adapter firmware. The firmware in turn pops the command address from the inbound post queue, sets up a DMA channel to fetch the command and processes the command. When the command is processed, the commands two status bytes and the command's ID are pushed onto the outbound post queue. When the adapter detects the availability of valid entries in the outbound post queue, the adapter sets a status bit in the outbound interrupt status register and sends an interrupt to the host. The host interrupt service routine (ISR) reads the status from the outbound message queue to process the status and thereby completes the cycle of command and status returned. The ISR can keep reading the outbound post queue until it receives a value of 0xffffffff that indicates the depletion of the outbound post queue's valid entries. Although multiple statuses are in the outbound post queue, the device driver's ISR must access the PCI bus and read the status from the outbound queue once per each status. With multiple adapters on a system, the device driver is contending with all other adapters for PCI bus resources. While the ISR is waiting for bus access, the ISR is tying up host CPU resources for servicing the ISR. In addition, due to speed mismatches between the host and the adapter, the ISR may read the first status and process the status before the adapter can replenish its staging status register from the status queue in local memory. During replenishment of the status register, the ISR is informed with an empty status (0xffffffff) and exits the routine. Once the status register is replenished after the ISR has exited, the bus needs to be interrupted again, requiring another ISR which may result in interrupt thrashing until the status queue is cleared.